On 2023-10-24 08:37, albert wrote:
> In article <uh63vl$37cua$
1...@dont-email.me>,
> Ruvim <
ruvim...@gmail.com> wrote:
>> On 2023-10-23 15:04, albert wrote:
>>> In article <uh5vno$36el4$
1...@dont-email.me>,
>>> Ruvim <
ruvim...@gmail.com> wrote:
>>>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>>>
>>>> In a nutshell:
>>>>
>>>> LATEST-NAME-IN ( wid -- nt|0 )
>>>> Remove the word list identifier wid from the stack. If this word list is
>>>> empty, then return 0, otherwise return the name token nt for the
>>>> definition that was placed most recently into this word list.
>>>>
>>>> LATEST-NAME ( -- nt )
>>>> Return the name token nt for the definition that was placed most
>>>> recently into the compilation word list, if such definition exists.
>>>> Otherwise throw exception code -80.
>>>>
>>>> Feedback is welcome!
>>>
>>> I hate to see NAME here. I advocate dea (dictionary entry address)
>>> since 1993 , working on the transputer Forth with Marcel Hendrix.
>>> There were N fields and N^2 transformation and I have had
>>> enough of it.
>>
>> "DEA" is an acronym. It's better to use a full English word if appropriate.
>
> This a slight disadvantage. However it conflicts with nothing.
I'm not against the term "DEA". It could be acceptable.
But at the moment, the term "name token" is already established, as well
as its designation "name" in the names of words.
What is wrong with that? Why is it worth changing to "dea"?
> There are Forth names that are abbreviations:
> R/O R/W SCR TIB SM/REM UM/MOD
> In the 30 years I have used DEA nobody has come up that catches the
> concept properly, and certainly anybody who has come up with a name that
> catches the concept improperly have found that is subject to confusion and
> infighting. On the other hand *nobody* has used "dea" in a conflicting
> way.
>
> "
> The DEA of a word identifies the word internally. It should be
> possible for the system to find all the properies of word
> knowing its DEA. In particular the executable code and its
> name (if it has a name)
> " ^^^^^^^^^^^^^^^^
>
> It bears repeating:
>
> ***********************************************************
> * Names are SO not determining the identity of a word. *
> ***********************************************************
I agree. A word name does not identify the word.
A name token identifies the word, by its definition:
A name token is a single-cell value that identifies a named Forth
definition.
In this context the term "token" does not mean a character sequence.
In a general sense, it is "something serving as an expression of
something else" --
https://en.wiktionary.org/wiki/token#Noun
>>
>> "NAME" has a long history. It denoted NFA, and now it denotes a name
>> token, which is successor of NFA — in all words except "PARSE-NAME", for
>> example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.
>>
>> There is no point in replacing "NAME" in all these words.
>> At the same time, naming for new words must be in consistence with
>> existing words.
> That is a non sequitur. In particular FIND-NAME is an example why
> the string NAME is a separate concept of the dea.
In "FIND-NAME" , "NAME" denotes a name token rather than a character
string. And it's a thing that is found.
If I understand right, in English, "to find x" means that "x" is the
thing that is found on success. In this case the found thing is a name
token, that is denoted as "NAME".
> Compare :
> FOUND ( sc -- dea )
> Look up the sc (addr len) in the current search order.
> Return *the* address dea, the address that rules them all.
The notion of memory address is too system specific for this purpose.
For example, in some plausible Forth system it can be an index in the
array of headers.
>>
>> [...]
>>>
>>> ***********************************************************
>>> * Names are SO not determining the identity of a word. *
>>> ***********************************************************
>>>
>>> I'm not against your proposal, only the names are wrong.
>>>
>>> >LATEST ( wid -- dea|0 )
>>> LATEST ( -- dea )
>>
>> The first name is not consistent with other similar names.
>>
>> And words with the second name already exist in many Forth systems, and
>> they behavior varies.
>
> Seriously? What with S>D >R U> EKEY>CHAR
Well, the right example is ">BODY" ( xt -- a-addr )
But I would prefer to avoid new standard words with names starting with
">", if this word is not for a stack related word.
> You are trying to win a debate here at any price. That doesnot get you
> points in a standard commission that must compromise.
> It is not a fraternety debate club.
It looks like you want to give me a piece of advice. A public place is
not suitable for this ;)
I just wonder, what a compromise do you have in mind in this particular
case? I mean, a compromise between which positions?
>>>> [1]
>>>>
https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124
>>>> Ruvim
>>>
>>> Groetjes Albert
>>>
>>> P.S. I use LATEST all over the place. I have a hard time to imagine
>>> a use for >LATEST. Unless ..
>>>
>>> Only define >LATEST. LATEST might be controversial so you avoid
>>> standardising it.
>>> On the top of the file you then can say
>>> : LATEST CURRENT @ >LATEST ;
>>
>> It's will be slightly longer.
>> In my proposal this word never returns 0, but throws an exception instead.
>>
>>> And get it over with.
>>> Same situation as with
>>> : NOT 0= ;
>
> I can't getting the point accross.
> The problem with LATEST that the obvious solution doesn't work.
> The naive solution reading iso93 is returning an xt.
> So what thingy is LATEST to return?
Sorry, I'm not following you here. I don't see how your question about
LATEST is related to my proposal.
--
Ruvim